Date: Mon, 6 Jun 94 04:30:19 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #182 

To: Ham-Digital 


Ham-Digital Digest Mon, 6 Jun 94 Volume 94 : Issue 182 


Today's Topics: 
An open note to Gary Coffman, KE4ZV (6 msgs) 
Ethernet address Directory? 
GRINOS AND ETHERNET 
Internet <-> Packet gateway (2 msgs) 

Motorola GPS engine purchase information 

NPFPMS update version 2.20A available 
Vester SSTV board 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 5 Jun 1994 20:31:14 GMT 

From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!wupost!crcnis1.unl.edu! 
ace.mid.net!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu! 
news.uiowa.edu!icaen!drenze@network.ucsd. 

Subject: An open note to Gary Coffman, KE4ZV 

To: ham-digital@ucsd.edu 


davidj@rahul.net (David Josephson) writes: 


>Gary's letter isn't here, but Doug's open letter is a fine start. And 
>we have all read replies about one technical angle or another being the 
>seed of our discontent. But have we ever thought about applications for 
>packet radio? Excuse me, but what is this thing for? 


If Gary will give his permission, I can post a copy of his letter. It's 
in the archives somewhere on our PBBS here. 


>Pedro Colla wrote a long article, pointing out what we have here: it is 

>a low bandwidth, anarchic, highly resilient network that will work, 
>eventually. Practical throughput, once there are more than two stations 
>involved, is a few tens or hundreds of baud. It is a thin network. Why 
>don't we give up on thinking of it as a ham Ethernet and start working 

>on more applications where this sort of information pipe will do some good? 


I agree--I wasn't necessarily suggesting that we should create an alternate 
Internet. The I-net examples I used were merely suggestions. I do think, 
though, that a TCP/IP network wouldn't be bad. Ie, e-mail could be handled 
by presently-existing SMTP applications. We could use things like FTPMail 
for file/data transfer. We could replace the existing haphazard system 
of bulletins with something using existing Usenet protocols, mail routing 
would be expedited. 

It would also be easier to support things such as (I think) 
Gary Coffman suggested--ie, a simple FORTH-like language to carry out 
remote tasks. I envision something like: 


: MAIN 
"STING" dbselect ( selects the database to be searched ) 
"worf" "riker" "troi" and and ( selects keywords to search for ) 
"picard" "riker" or not and ( selects keywords to exclude ) 
SEARCH ( executes the database search ) 


' 


which could then be compiled into a tokenized string that would be uploaded 
to the interpreter and executed. If it worked, it'd self-delete and mail 
the results back to the originator, else it would be passed onto the next 
computer in the chain. 

I've actually sort of spec'ed out something along these lines. It 
wouldn't necessarily have to support recursion in the initial stages, and 
could be written with a relatively simple YACC grammar, methinks. I think 
that the TinyMUCK code which supports the MUF programming language would be 
a good example of how something like this could work. 


Ack. I guess I've gotten off my original track. But anyway. This is, 
BTW, something which could be adapted to the Internet with fantastic 
results. Imagine being able to mail such a search program off to an 
archie server, or a network of WAIS servers. 

Food for thought. 

73 - doug 


>73 
>David WA6NMF 


>-- 
>David Josephson / Josephson Engineering / San Jose CA / david@josephson.com 
Doug Renze, NOYVW x drenze@isca.uiowa.edu * NOYVW @ WOIUQ.ia.usa.na 
DRenze@aol.com xx drenze@chop.isca.uiowa.edu 


Date: Sun, 5 Jun 1994 11:44:09 GMT 

From: ihnp4.ucsd.edu! agate! howland.reston.ans.net! pipex!uknet!cix.compulink.co.uk! 
packman@network.ucsd.edu 

Subject: An open note to Gary Coffman, KE4ZV 

To: ham-digital@ucsd.edu 


> Hmmm...must ask my local Satgate operator about getting (another) > look 
> at the programs. Sounds like it could be an interesting 
> experiment...even more interesting if the source code was available. 


Just asked him and he says that whilst PB/PG (the user progs) are readily 
available, he's never seen a Pacsat simulator program around. He reckoned 
it might not be available due to ‘commercial’ interests in the satellite 
program :( 


Chris - G6FCI Packet : G6FCI @ GB7FCI.#16.GBR.EU 
Internet : packman@cix.compulink.co.uk 


Date: 6 Jun 1994 04:58:02 GMT 

From: nothing.ucsd.edu! brian@network.ucsd.edu 
Subject: An open note to Gary Coffman, KE4ZV 
To: ham-digital@ucsd.edu 


packman@cix.compulink.co.uk ("Chris Mcmahon") writes: 
>For Mr Joe User who is a black box operator that buys a TNC off the shelf 


I do not sympathise with people who refuse to learn the state of the 
art. They have chosen not to keep up; if they therefore can't do some 
of the more advanced things, that is the result of THEIR DECISION. 


A falsely-perceived need for backwards-compatability has held back more 
progress than all the world's Luddites combined. 


- Brian 


Date: 6 Jun 1994 04:54:26 GMT 


From: nothing.ucsd.edu! brian@network.ucsd.edu 
Subject: An open note to Gary Coffman, KE4ZV 
To: ham-digital@ucsd.edu 


WB6YMH and I proposed the news broadcast scheme some years ago; it's 
been tossed around a number of times since, but no one has gotten around 
to writing the actual client (there is a sender). Certainly the various 
clients intended for use with the PACSATS could (and do) work, but a 
more purpose-built client would be better. 


I envision that the news would be broadcast CONTINUOUSLY in round-robin 
fashion - no need for the transmitter to ever unkey. New articles would 
be added and old ones expired from the list over time. 


User stations would run a background process (a "TSR" in MS-DOG parlance) 
that would suck in the articles as they're broadcast (selectively or not 
as the user specified), squirrel them away on disk, and update an index. 
Since the user station never has to transmit - fills happen automatically 
from the repeated broadcasts and error-correction coding could help - 
there's no issue of unattended transmitter operation - it's receive only! 


When the user stopped playing space blaster, gets back from the office, 
or whatever, he'd be able to fire up a news reader and read the articles 
that had appeared. Read them FAST, off local disk, not over the air. 


I know that the idea of a continuous bulletin transmission doesn't sit 
well with a lot of hams, but in the USA it's legal and it's clearly efficient. 


Some day I or someone else will write the client and then it'll be time 
to clank on the sender. You know, a single 10-watt transmitter on a 
Single 2m frequency on one mountaintop here in SoCal could cover 
thousands of square miles and serve thousands of hams all at once. 

- Brian 


Date: Sat, 4 Jun 1994 14:50:49 +0000 

From: ihnp4.ucsd.edu!agate!doc.ic.ac.uk!uknet! demon! djwhome.demon.co.uk! 
david@network.ucsd.edu 

Subject: An open note to Gary Coffman, KE4ZV 

To: ham-digital@ucsd.edu 


In article <1994Jun2.105141.15184@cnsvax.uwec.edu> whitemp@hemp (Mike White) 
writes: 

>Actually, the solution, as I see it, is to modify the 8250slip.com (or 
>whatever they call it nowadays) so that it operates with KISS rather 

>than slip. KA9Q does a fine job, true, but it is an application and not 


It's not quite as simple as this. Amateur packet is a broadcast medium and 
needs an address resolution protocol. SLIP is a point to point protocol and 
doesn't use an address resolution protocol. A lot of TCP/IP software 
actually doesn't support SLIP class drivers, so there are SLIP drivers which 
spoof ARP to keep the stack happy. Also packet drivers assume that the 
higher software provides MAC level header information. To run with normal 
stacks, you have to run ARP within the packet driver and map ethernet or 
token ring addresses into callsigns within the driver. (I think you also 
have to handle parts of the AX.25 protocol, if you are using KISS.) 


I seem to remember that there is an AX.25 class for packet drivers, but that 
would only work with AX.25 aware stacks (will KA9Q work with such drivers?). 
All this processing is going to make a KISS packet driver big and non-trivial 
to write, but not impossible. It may have been done, but I would have 
expected it to have been mentioned in this thread by now, if that were the 
case. 

David Woolley, London, England david@djwhome.demon.co.uk 
Demon is an IP/SMTP/NNTP Provider. *.demon hosts are independently managed. 


Date: Sun, 05 Jun 1994 19:50:00 PST 

From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gstefsd.com! 
newsxfer.itd.umich.edu!nntp.cs.ubc.ca!mala.bc.ca!epaus!ham!emd@network.ucsd.edu 
Subject: An open note to Gary Coffman, KE4ZV 

To: ham-digital@ucsd.edu 


davidj@rahul.net (David Josephson) writes: 


>ARESPACK from WN6I tracks who/where/what during a disaster. APRS plots 
>locations of stations, DF headings, station status, etc on a map from 
>information transmitted on packet. And the DX cluster is a perfect 
>example of how we can use this mode to make things nicer. 

> 


ARESPACK sounds like just the thing I could use here as ESS Comms 
director. Where can I find it? 


Tnx, Bob. 
emd@ham.island.net (Robert Smits Ladysmith BC) 


Date: 5 Jun 1994 10:48:31 GMT 
From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!EU.net!Austria.EU.net! 


newsfeed.ACO.net!nippur.irb.hr!thphys!sinisa@network.ucsd.edu 
Subject: Ethernet address Directory? 
To: ham-digital@ucsd.edu 


In <BAT.94Jun3070029@gsdstech.GRUMMAN.COM> bat@gdstech.GRUMMAN.COM (Pat Masterson) 
writes: 


> Each vendor has a whole BLOCK of ethernet addresses. So, each card 
>they make can have a different address. These blocks are listed in 
>an RFC, but I don't remember which one. And, for new ones, or 
>those that don't seem to be listed, you can call the IEEE and ask 
>them. They might not tell you who the vendor is, but they can have 


Also look on FTP.LCS.MIT.Edu , file pub/map/EtherNet-codes 
(via anonftp, of course). 
Great! 


>a vendor rep call you back if you need to identify some wayward 
>ethernet address. 


>-- 

Deon nen ne eee * 
>* Pat Masterson D12-25 | KE2LI@KC2FD * 
>* Grumman Data Systems | 516-346-6316. * 
>* Bethpage, NY 11746 | bat@gdstech. grumman.com * 
Sinisa 


! Sinisa Novosel, Institut Rugjer Boskovic, dep. FIZIKA; Croatia,Zagreb ! 
! sinisa@thphys.irb.hr ! 


Date: Sun, 5 Jun 94 08:54:28 GMT 

From: ihnp4.ucsd.edu!usc!math.ohio-state.edu!caen!news.umass.edu!nic.umass.edu! 
usenet@network.ucsd.edu 

Subject: GRINOS AND ETHERNET 

To: ham-digital@ucsd.edu 


In Article 
<"940602.14:00:42*.G=KRISTOFF.S=BONNE.OU=PIRESSYS.O=BELGACOM.PRMD=RTTIPC.ADMD=RTT. 
C=BE."@MHS> 

kbonne@nx.xrtt.rtt.BE (Kristoff BONNE) writes: 


>I've put NOS on a PC at my qrl to do some tests on the LAN. 


>When I send/receive ‘a lot' of data ('a lot' being some hundred bytes), the 
>session hangs. (the rest of NOS still works OK?) 


I don't have an answer, but have seen the problem with a slightly different 
configuration (386, and a different packet driver). It occurs when I connect 
via ethernet to a VAX or a Sun, both of which are set up to service large 
numbers of users. The VAX session usually hangs up before it gets through 
the messages of the day. The Sun will crash when I do an ls -1l command 

on a moderately big directory. 


I inquired on other groups about this and was given a suggestion that the 
telnet escape character default for NOS was the problem, but in fact it made 
no difference. 


I suspect the problem may be that NOS does dynamic memory allocation and 

just can't do it fast enough to handle a large amount of data coming in fast, 
i.e., at ethernet speeds. Try using the "mem stat" command after this happens. 
I think a solution might be to recompile a NOS with less stuff in it, to use 
less memory. But I've never tried this. 


The problem is not inherent in the ethernet interface per se, I can connect 
NOS via ethernet to another NOS box, to a Minix box, or to a couple of Linux 
systems. But these systems don't output as much data as the VAX or Sun. 


Albert S. Woodhull 
Hampshire College, Amherst, MA, USA 
awoodhull@hamp. hampshire. edu 


Date: 5 Jun 1994 20:50:34 GMT 

From: bloom-beacon.mit.edu!senator-bedfellow.mit.edu!mit.edu!maui@uunet.uu.net 
Subject: Internet <-> Packet gateway 

To: ham-digital@ucsd.edu 


Hi there: 


This question is coming from someone who is Internet experienced but has 
very little HAM experience. I am looking for a gateway to communciate 
with someone who has an address on a Packet BBS in AZ. I know gateways 
between the Internet and Packet exist. Can someone tell me where one is 
and how to use it? Please e-mail me the answer to this question since I 
don't really read this newsgroup. 


- Thanks - 


(|)axrk Uhrmacher 


maui@mit.edu 


Date: 06 Jun 1994 01:35:17 GMT 

From: yale.edu!noc.near.net!chaos.dac.neu.edu!chaos.dac!wy1z@yale.arpa 
Subject: Internet <-> Packet gateway 

To: ham-digital@ucsd.edu 


In article <MAUI.943un5165034@xv.mit.edu> maui@mit.edu (Mark A Uhrmacher) writes: 


Path: chaos.dac.neu.edu! grapevine.lcs.mit.edu!olivea!decwrl!ames!agate! 
howland.reston.ans.net!pipex!sunic!trane.uninett.no!eunet.no!nuug!EU.net!uunet! 
bloom-beacon.mit.edu!senator-bedfellow.mit.edu!mit.edu!maui 

From: maui@mit.edu (Mark A Uhrmacher) 

Newsgroups: rec.radio.amateur.digital.misc 

Date: 5 Jun 1994 20:50:34 GMT 

Organization: Massachusetts Institute of Technology 

Lines: 13 

Distribution: world 

NNTP-Posting-Host: xv.mit.edu 


Hi there: 
This question is coming from someone who is Internet experienced but has 
very little HAM experience. I am looking for a gateway to communciate 
with someone who has an address on a Packet BBS in AZ. I know gateways 
between the Internet and Packet exist. Can someone tell me where one is 
and how to use it? Please e-mail me the answer to this question since I 
don't really read this newsgroup. 
- Thanks - 
(|) ark Uhrmacher 
maui@mit.edu 
Check out: oak.oakland.edu:/pub/hamradio/docs/packet-internet 
There is gateway info there. 


If you need any help, please let me know. 


Scott 


| Scott Ehrlich Amateur Radio: wy1z AMPRnet: wy1z@Qwalphy.ampr.org | 


| Internet: wy1z@neu.edu BITnet: wy1zZ@NUHUB AX.25: wy1z@wailphy.ma.usa.na | 


| Maintainer of the Boston Amateur Radio Club hamradio FTP area on | 
| oak.oakland.edu - /pub/hamradio 


Date: Sat, 4 Jun 1994 14:30:58 GMT 

From: ihnp4.ucsd.edu!usc!cs.utexas.edu!utnut!torn!uunet.ca!uunet.ca!geac!torsqnt! 
problem! vigard!mdf@network.ucsd.edu 

Subject: Motorola GPS engine purchase information 

To: ham-digital@ucsd.edu 


alanb@sr.hp.com (Alan Bloom) writes: 

>Marc T. Kaufman (kaufman@Xenon.Stanford.EDU) wrote: 

>: ... the GPS measured position changes with time (dithers). 

> 

>What is the time constant of the GPS Selective Availability dithering? 
>Does it change on the order of hours, minutes, seconds or even faster? 


minutes, i believe. the marine DGPS systems being setup by the US and 
Canadian coast guards broadcast pseudo-range corrections, at 50 bits 
per second, on top of existing navigation beacons in the 300-500kHz area. 


>AL N1AL 
Matthew Francey mdf@vigard.mef.org ve3rqx@io.org 
"live before you die" GPS(NAD27): N43034.210' WO79034.563' +0093m 


Date: Sun, 5 Jun 1994 11:50:58 +0000 

From: ihnp4.ucsd.edu! swrinde! pipex!demon! g8dzh.demon.co.uk! John@network.ucsd.edu 
Subject: NPFPMS update version 2.20A available 

To: ham-digital@ucsd.edu 


Version 2.20a of the G8NPF Personal Message System (NPFPMS) is now available 
as a self-exploding file 'NPF220A.EXE'. NPFPMS is designed to be used with 
G8BPQ node software (version 4.05 or greater) on PC-AT class (286 and higher) 
machines. New functions since the last Internet release 2.16d include: - 


* Support for FBB Unproto broadcasts to maintain message lists. Messages read 
from FBB BBS's by the AutoRead function can use compressed file format. 


* Archive Message facility added. 


* Virtual (ram) disk (or a different hard disk) support for temporary files. 


*x Extensions added to YAPP transfer protocol. 
Crash recovery. Resume an aborted file download. 
YappC checksum mode. (as used by FBB) 


Plus many other improvements. NPF220A.EXE and information file NPF220A.TXT can 
be ftp'ed from : 


ftp.demon.co.uk [158.152.1.69] /pub/ham 

ftp.funet.fi [128.214.248.6] /pub/ham/packet/misc 
John Ray | Internet: John@g8dzh.demon.co.uk 
Loughton | CI$ 100041, 305 
Essex | AMPRnet: g8dzh@gb7ine.ampr.org [44.131.182.1] 
England | AX25: G8DZH@GB7HSN .#32.GBR.EU 


Date: Mon, 6 Jun 1994 01:13:19 GMT 

From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!news.umbc.edu! eff! 
news .kei.com!ub! freenet.buffalo.edu!aa450@network.ucsd.edu 

Subject: Vester SSTV board 

To: ham-digital@ucsd.edu 


In a previous article, jeff.smith@n9csa.com (Jef£ Smith) says: 
>Hey guys, 


>Can anybody make a Vester SSTV board ( QST Jan. 1994) for me? I will pay 
>you $$. I am a new ham awaiting my ticket but I have no electrical 


>knowledge. Please help!!! Leave me a message. 
>Thanks and 73's, Jeff 
> 


FAR has that board for sale. See their add for address. It's < $5. 


But... the circuit is so simple you can use a scrap of perfboard just 
as well. I bumped into Ben Vester at Dayton and he pulled his out of 
a pocket to show me, and.... it was a 2" square of perfboard. 


Good luck, Kurt 


Date: Mon, 6 Jun 94 09:09:08 GMT 

From: ihnp4.ucsd.edu! swrinde! pipex!uknet!uos-ee!ee.surrey.ac.uk! 
M.Willis@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <1994Jun3.150706.7300@ke4zv.atl.ga.us>, 
<CqvMru.A3D@cix.compulink.co.uk>, <2suacq$fvt@network.ucsd.edu>,, 
Subject : Re: An open note to Gary Coffman, KE4ZV 


In article <2suacq$fvt@network.ucsd.edu>, brian@nothing.ucsd.edu (Brian Kantor) 
writes: 

|> packman@cix.compulink.co.uk ("Chris Mcmahon") writes: 

|> >For Mr Joe User who is a black box operator that buys a TNC off the shelf 
|> 

|> I do not sympathise with people who refuse to learn the state of the 

|> art. They have chosen not to keep up; if they therefore can't do some 

|> of the more advanced things, that is the result of THEIR DECISION. 

|> 

|> A falsely-perceived need for backwards-compatability has held back more 

|> progress than all the world's Luddites combined. 

|> - Brian 


And a falsely-perceived need for change has held back progress even more. You 
can't 

just write off a worlds worth of equipment because it is now possible to go twice 
as quickly. 


Regarding your lack of sympathy, are you unsympathetic to the unwilling or the 
incapable? 


How many times does it need to be proved that the average person does not 

have the intellect to keep up with the state of the art? Perhaps we should take 
away the licences of all those black boxers who can not pass a new, suitably 
difficult, technical exam? 


The reason people refuse to learn the state of the art is that the majority of 
those who are at that level are either incapable of teaching others or make things 
so difficult to understand that no-one else has a chance. For example, TCP/IP. 
There are a lot of developers out there who have written some very clever 
software. 

In the main the manuals are terrible. They are concise, exact and tell the 
beginner 

nothing. Acronyms are used all over the place, yet no list of acronyms is provided 
so you need to remember each one. Software that is not easy to use is bad 
software. 

If you require a large amount of technical insight to use an item, then it is 
badly 

designed. 


When it is so hard to get started, no wonder those with less ability give up. I 
agree that we need to get rid of the CB mentality type of black box operator who 
knows nothing and is able, but not prepared, to learn. 


Date: Mon, 6 Jun 1994 00:58:09 GMT 
From: news.Hawaii.Edu!uhunix3.uhcc.Hawaii.Edu! jherman@ames.arpa 
To: ham-digital@ucsd.edu 


References <2skvhe$qov@Times.Stanford.EDU>, <CqsAx8.155@srgenprp.sr.hp.com>, 
<1994Jun4.143058.18107@vigard.mef.org> 
Subject : Re: Motorola GPS engine purchase information 


In article <1994Jun4.143058.18107@vigard.mef.org> mdf@vigard.mef.org (Matthew 
Francey) writes: 

> 

>minutes, i believe. the marine DGPS systems being setup by the US and 
>Canadian coast guards broadcast pseudo-range corrections, at 50 bits 

>pexr second, on top of existing navigation beacons in the 300-500kHz area. 


That wouldn't be very helpful to the ham community - those beacons 
you speak of (285-325 kc is the maritime beacon band; the aeronautical 
beacons operate from 200 to 415 kc) only have a range from 5 to 50 miles. 


Jeff NH6IL 


End of Ham-Digital Digest V94 #182 
KKKKKKKKKKKKKKKKKKKKKEKKEKRKE ARK KIK 


